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Network-Assigned Upstream Label 
Abstract 


This document discusses a Generalized Multi-Protocol Label Switching 
(GMPLS) Resource reSerVation Protocol with Traffic Engineering 
(RSVP-TE) mechanism that enables the network to assign an upstream 
label for a bidirectional Label Switched Path (LSP). This is useful 
in scenarios where a given node does not have sufficient information 
to assign the correct upstream label on its own and needs to rely on 
the downstream node to pick an appropriate label. This document 
updates RFCs 3471, 3473, and 6205 as it defines processing for a 
special label value in the UPSTREAM LABEL object. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8359. 
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1. Introduction 


A functional description of the Generalized Multi-Protocol Label 
Switching (GMPLS) signaling extensions for setting up a bidirectional 
Label Switched Path (LSP) is provided in [RFC3471]. The GMPLS 
Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) 
extensions for setting up a bidirectional LSP are specified in 
[RFC3473]. The bidirectional LSP setup is indicated by the presence 
of an UPSTREAM_LABEL object in the Path message. As per the existing 
setup procedure outlined for a bidirectional LSP, each upstream node 
must allocate a valid upstream label on the outgoing interface before 
sending the initial Path message downstream. However, there are 
certain scenarios (see Section 4) where it is not desirable or 
possible for a given node to pick the upstream label on its own. 
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This document defines the protocol mechanism to be used in such 
scenarios. This mechanism enables a given node to offload the task 
of assigning the upstream label for a given bidirectional LSP to 
nodes downstream in the network. It is meant to be used only for 
bidirectional LSPs that assign symmetric labels at each hop along the 
path of the LSP. Bidirectional Lambda Switch Capable (LSC) LSPs use 
symmetric lambda labels (format specified in [RFC6205]) at each hop 
along the path of the LSP. 


As per the bidirectional LSP setup procedures specified in [RFC3471] 
and [RFC3473], the UPSTREAM_LABEL object must indicate a label that 
is valid for forwarding. This document updates that by allowing the 
UPSTREAM_LABEL object to indicate a special label that isn’t valid 
for forwarding. As per the bidirectional LSC LSP setup procedures 
specified in [RFC6205], the LABEL SET object and the UPSTREAM LABEL 
object must contain the same label value. This document updates that 
by allowing the UPSTREAM_LABEL object to carry a special label value 
that is different from the one used in the LABEL SET object. 


2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


3. Unassigned Upstream Label 


This document defines a special label value -- "OxFFFFFFFF" (for a 
4-octet label) -- to indicate an Unassigned Upstream Label. Similar 
"all-ones" patterns are expected to be used for labels of other 
sizes. 

0 1 2 3 


01234567890123456789012345678<9021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|1 DE DG DECH e EE e E De Ee E DEE De a WE D a ed 1| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 1: Unassigned UPSTREAM_LABEL - "all-ones" Pattern 
The presence of this value in the UPSTREAM_LABEL object of a Path 
message indicates that the upstream node has not assigned an upstream 


label on its own and has requested the downstream node to provide a 
label that it can use in both the forward and reverse directions. 
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3; 


sees 


The presence of this value in the UPSTREAM_LABEL object of a Path 
message MUST also be interpreted by the receiving node as a request 
to mandate symmetric labels for the LSP. 


Procedures 


The scope of the procedures is limited to the exchange and processing 
of messages between an upstream node and its immediate downstream 
node. The Unassigned Upstream Label is used by an upstream node when 
it is not in a position to pick the upstream label on its own. In 
such a scenario, the upstream node sends a Path message downstream 
with an Unassigned Upstream Label and requests the downstream node to 
provide a symmetric label. If the upstream node desires to make the 
downstream node aware of its limitations with respect to label 
selection, it MUST specify a list of valid labels via the LABEL SEIT 
object as specified in [RFC3473]. 


In response, the downstream node picks an appropriate symmetric label 
and sends it via the LABEL object in the Resv message. The upstream 
node would then start using this symmetric label for both directions 
of the LSP. If the downstream node cannot pick the symmetric label, 
it MUST issue a PathErr message with a "Routing Problem/Unacceptable 
Label Value" indication. If the upstream node that signals an 
Unassigned Upstream Label receives a label with the "all-ones" 
pattern or any other unacceptable label in the LABEL object of the 
Resv message, it MUST issue a ResvErr message with a "Routing 
Problem/Unacceptable Label Value" indication. 


The upstream node will continue to signal the Unassigned Upstream 
Label in the Path message even after it receives an appropriate 
symmetric label in the Resv message. This is done to make sure that 
the downstream node would pick a different symmetric label if and 
when it needs to change the label at a later time. If the upstream 
node receives an unacceptable changed label, then it MUST issue a 
ResvErr message with a "Routing Problem/Unacceptable Label Value" 
indication. 
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+---------- + Kësse + 
Path 
Upstream Label (Unassigned) 
Label-Set (L1, L2 ... Ln) 
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Resv 
Label (Assigned - L2) 
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Figure 2: Signaling Sequence 
3.2. Backwards Compatibility 


If the downstream node is running an implementation that doesn’t 


support the semantics of an Unassigned UPSTREAM LABEL, 
reject the special label value and generate an error as specified 


(a) 
in Section 3.1 of [RFC3473] 
label. 


or 


If the behavior that is exhibited is 


compatibility concerns. If the 


then the downstream node will send a label with the 
pattern in the LABEL object of the Resv message. 


upstream node will issue a Resv 
Unacceptable Label Value" 


Use-Case: Wavelength Setup for 


Consider the network topology depicted in Figure 3. 


it will either 


(b) accept it and treat it as a valid 


(a), then there are no backwards 
behavior that is exhibited is (b), 
"all-ones" 
In response, the 


Err message with a "Routing Problem/ 


indication. 


IP over Optical Networks 


Nodes A and B 


are client IP routers that are connected to an optical Wavelength 


Division Multiplexing (WDM) 
nodes. The transponder sits on 


transport network. 


F and I represent WDM 
the router and is directly connected 


to the add-drop port on a WDM node. 


The optical signal originating on "Router A" 
it gets multiplexed with optical 
Depending on the implementation of 
it may not be acceptable to have the 


wavelength. On "WDM-Node F", 
Signals at other wavelengths. 
this multiplexing function, 
router send the signal into the 
appropriate wavelength. 
signals with a wrong wavelength 
trails. 
network, 
advance. 
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Standards Track 


is tuned to a particular 


optical network unless it is at the 
having the router send 
may adversely impact existing optical 


If the clients do not have full visibility into the optical 
they are not in a position to pick the correct wavelength in 
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The rest of this section examines how the protocol mechanism proposed 
in this document allows the optical network to select and communicate 
the correct wavelength to its clients. 


4.1. Initial Setup 


Eresch /-\ /-\ Frek 
|A [A CRI Ee ee GZ 
+S Yer Vd ese 
Path 
Upstream Label (Unassigned/0OxFFFFFFFF) 
Sy ak Sei eae ere E eege Seng ett Sa Weg > 
-- 77 == 77 ==> 
Path 
gett ee ge e E e ht See re pe en > 
Resv 
< (eee er Same, ee Se a esa se Sal En teams ge 
<== 77 = 77 2 
Resv 


Label (Assigned) 


Figure 3: Initial Setup Sequence 


Steps: 


o "Router A" does not have enough information to pick an appropriate 
client wavelength. It sends a Path message downstream requesting 
the network to assign an appropriate symmetric label for its use. 
Since the client wavelength is unknown, the laser is off at the 
ingress client. 


o The downstream node (Node F) receives the Path message, chooses 
the appropriate wavelength values, and forwards them in 
appropriate label fields to the egress client ("Router B"). 


o "Router B" receives the Path message, turns the laser ON and tunes 
it to the appropriate wavelength (received in the UPSTREAM_LABEL/ 
LABEL_SET of the Path) and sends a Resv message upstream. 


o The Resv message received by the ingress client carries a valid 
symmetric label in the LABEL object. "Router A" turns on the 
laser and tunes it to the wavelength specified in the network 
assigned symmetric LABEL. 
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For cases where the egress-node relies on RSVP signaling to determine 
exactly when to start using the LSP, implementations may choose to 
integrate the above sequence with any of the existing graceful setup 
procedures: 


o "“ResvConf" setup procedure ([RFC2205]) 

o Two-step "ADMIN STATUS" based setup procedure ("A" bit set in the 
first step; "A" bit cleared when the LSP is ready for use) 
([RFC3473]) 

4.2. Wavelength Change 


After the LSP is set up, the network may decide to change the 


wavelength for the given LSP. This could be for a variety of reasons 
including policy reasons, restoration within the core, preemption, 
etc. 


In such a scenario, if the ingress client receives a changed label 
via the LABEL object in a modified Resv message, it retunes the laser 
at the ingress to the new wavelength. Similarly, if the egress 
client receives a changed label via UPSTREAM_LABEL/LABEL_ SET in a 
modified Path message, it retunes the laser at the egress to the new 
wavelength. 


5. IANA Considerations 


IANA maintains the "Generalized Multi-Protocol Label Switching 
(GMPLS) Signaling Parameters" registry. IANA has added a new 
subregistry titled "Special Purpose Generalized Label Values". New 
values are assigned according to Standards Action [RFC8126]. 


Special Purpose Generalized Label Values 


Pattern/ Label Name Applicable Reference 
Value Objects 
all-ones Unassigned UPSTREAM LABEL [RFC8359] 


Upstream Label 
6. Security Considerations 


This document defines a special label value to be carried in the 
UPSTREAM LABEL object of a Path message. This special label value is 
used to enable the function of requesting network assignment of an 
upstream label. The changes proposed in this document pertain to the 
semantics of a specific field in an existing RSVP object and the 
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corresponding procedures. Thus, there are no new security 
implications raised by this document and the security considerations 
discussed by [RFC3473] still apply. 


For a general discussion on MPLS and GMPLS related security issues, 
see the MPLS/GMPLS security framework [RFC5920]. 
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